On the Design of a Tool for Supporting the Construction of 

Logic Programs* 

o . 

O ■ Gustavo A. Ospina 

\ Baudouin Le Charlier 

Departement d'Ingenierie Informatique, Universite Catholique de Louvain 
Place Sainte Barbe 2, B-1348 Louvain-la-Neuve, Belgium 
{gos ,blc}@inf o .ucl . ac .be 



O 
(N 



. Abstract 

^ \ Environments for systematic construction of logic programs are needed in the academy 

as well as in the industry. Such environments should support well defined construction 
methods and should be able to be extended and interact with other programming tools 
like debuggers and compilers. We present a variant of the Deville methodology for logic 
program development, and the design of a tool for supporting the methodology. Our aim 
is to facilitate the learning of logic programming and to set the basis of more sophisticated 
tools for program development. 
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Introduction 

Logic Programming is a suitable paradigm for supporting methods and techniques of software 
engineering, as shown in [Qj. However, there are relatively few attempts to bring software 
support to logic program construction. 

The interest in having computer tools to help logic program development is twofold: tools 
can help novice programmers and students to get skills in the programming paradigm; on the 
other hand, in an industrial context, tools can make logic programming more widely used in 
the development of large software systems. 

Tools are usually designed to give (semi)automatic support to methodologies of program de- 
velopment. Well defined methodologies help the programmer in the construction process, 
starting from a specification, to get a program which is correct with respect to that speci- 
fication. There are several methods to support the construction of logic programs. We can 
mention Deville's Methodology jl, Stepwise Enhancement || with its higher order extensions 



[10] and Synthesis from Schemas 



In this paper we present some notes on the design of a tool to support Prolog program devel- 
oment based on a variant of Deville's methodology @. This variant adds a type system and 
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the notion of typed logic description, which allows a possible adaptation of the methodology 
for program construction in typed logic languages like Mercury ||. Our tool is designed to 
help students in their learning of logic programming, and to bring another chance in the 
development of CASE tools for this paradigm. 

The paper is structured as follows. The next section describes the variant to Deville's Method- 
ology for logic program development. Section 2 gives details on the design of a tool to support 
the methodology. Section 3 will conclude and give perspectives for further work. 

1 Methodology for Logic Program Construction 

The original methodology proposed by Deville in M consists of three steps: 

1. Elaboration of a specification 

2. Construction of a logic description 

3. Derivation of a logic procedure 

The result of the application of the methodology is the set of clauses for a logic procedure 
p/n, this is, clauses with the same head p(Xl, . . . ,Xn). When the methodology is correctly 
applied, the logic procedure is correct with respect to its specification. 

Our new contribution to the original methodology is the division in the second step: 

1. Elaboration of a specification 

2. (a) Construction of a typed logic description 

(b) Conversion of the typed logic description into a non-typed logic description 

3. Derivation of a logic procedure 

We add a simple type system to support the construction of typed logic descriptions. Such 
typed logic descriptions are more suitable to be translated to typed logic languages. 

1.1 Elaboration of a specification 

Specifications follows the template proposed by Deville and revised in the FOLON project 
|7]], with slight modifications. The specification template is shown in Fig. 1. 

We use the same approach of the methodology of having types as sets of ground terms. 
However, we also define a type system to restrict the sets that can be considered as a type. 
The type system is described in the next section. 

A directionality for a procedure p/n has the form: 



(Mi,...,M n ): Mult: Nosh 
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procedure p(Xi,...,X n ) 

Types: 
Xi : typei 



X n : type n 
Relation: 

Description of a relation between the parameters Xi,...,X n 
Directionalities: 

Description of directionalities, with mode, determinism and no sharing 
information 

External conditions: 

Description of the external environment preconditions and side effects 

Figure 1: General specification template 

Where: 

• Mi = Irii i— ► Outi, In,i,Outi € {ground, ngv, var, novar, gv, noground, any}. A 
singleton Mode abbreviates Mode h- > Mode. 

• Mult = < Min - Max > where Min, Max € N U {*, 00} 

• No_sh is a set of pairs 7^ j and i,j S l..n 

The Mi bindings are usually called the modes of the procedure. We decided to represent 
them in the form Im 1— > Outi to make them more intuitive and closer to mode declarations 
in Mercury. 

Mult is the determinism associated with modes Mj. It estimates the lower and upper bounds]] 
in the number of answer substitutions of the procedure when it is invoked with a entry 
substitution respecting to the Ini in the mode declaration. Fig. 2 shows a correspondance 
between mode and determinism declaration in our specification template and the ones used 
by Mercury. 

Nosh is a set of pairs (i, j), each pair means that parameters T and Tj do not share variables. 
It can be seen as a partial description of a reflexive and symmetric relation on the set of 
parameters. 



1 A bound '*' indicates a fixed but unknown number of answer substitutions, whereas '00' indicates infinite 
answer substitutions 



4 



WLPE'Ol 



Mercury 


< Min- Max > 


Mercury 


In \— > Out 


determinism 


determinism 


mode 


directionality 


det 


< l - l > 


in 


ground i— > ground 


semidet 


< 0- 1 > 


out 


var i— > ground 


nondet 


< - * >< — oo > 


di 


ground i— > ground 


multi 


< 1 — * >< 1 — oo >< * — * > 


uo 


var i— > ground 


failure 


< 0-0 > 


User 


any t— > any 


erroneous 


< 1 -0 > 


defined 





Figure 2: Comparison with Mercury modes and determinism 
1.2 Construction of a Typed Logic Description 

We recall the definition of a (non typed) Logic Description according to Deville Q : 

Definition 1. A (non typed) logic Description is a closed first order logic formula of the 
form 

VX l ..XX n .p(X u ...,X n )&Def 

Where Def, the definition part of the logic description, is a closed first order logic formula. 
(Non typed) logic descriptions are denoted as LD(p/n). 

For the sake of simplicity, we omit the universal quantifiers in p(X\, ...,X n ) and assume the 
free variables in Def as existentially quantified. 

In j|| the notion of correction of a logic description with respect to its specification is de- 
fined, and some construction techniques based on structural induction are proposed, in order 
to build the definition part of the logic description. The resulting logic description is "correct 
by construction" . 

The structural induction technique to build the definition part of LD(p/n) produces a logic 
description of the form 

p(X u ...,X n ) & (Ci A Ft) V ... V (C m A F rn ) 

In the following, we call Term to be the set of all the ground terms. 

The definition part of the logic description is obtained after following these steps: 

• Choose induction parameters on parameters Xi,...,X n , denoted Ii,...,I p (p < n) 

• Find a well-founded relation over the cartesian product TermP . Such relations are found 
with the help of type information. 

• Define the structural forms C±, C m of induction parameters Ii,...,I p , according to the 
well-founded relation. 

• Build the structural cases. For each Ci, build the corresponding Fi, which is a logic 
formula that makes true the predicate p whenever d is true. Fi can have occurrences 
of p. 
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• Add type-checking literals when needed. 

Variants of this technique include tupling generalization and introduction of accumulators |4j . 

We will see that these techniques are still applicable for typed logic description, with the 
advantage of a better handling of type-checking literals. This requires the definition of a type 
system. 

1.2.1 Type system 

According to the original methodology, a type is simply an arbitrary set of ground terms. We 
propose a type system which describes such sets in a more structured way. Our type system is 
enoughly expressive to describe several useful types, altough it lacks some desirable features 
of modern type systems like parametric polymorphism. 

The set Term is the only type which contains all the other types. 

A type is described with a non typed logic description over an unary predicate, which has 
this form: 

type(X) 44> TypeDef 
TypeDef cannot be any logic formula. It must have one of these forms: 

• C\ V ... V C m where each Ci is a conjunction X = typejzons{X\, Xi) A type\(X\) A 
... A typei(Xi). To abbreviate we can omit the occurrences of term(X) for any variable 
X, since it is equivalent to true. Note that the name of the type to be defined can occur 
in the C{. A type defined in that way is called recursively defined. 

• another -type(X). In this way one describes a type equivalence. It means that the 
definition of type is equal to the definition of another _type. Types cannot be mutually 
recursive. For instance it is not allowed to have two types t\ and t 2 defined as: 

h(X)^t 2 (X) 
t 2 (X)^c(Y)Vt 1 (Y) 

Describe enumeration types is easy with this syntactic sugar: 

enum_type{X) «Ie {atomic ...,atom m } 

is equivalent to 

enum_type{X) X = atom\ V ... V X = atom m 
These are some examples of types: 

• fruit(X) «l£ {orange, apple, banana, pineapple, strawberry} 

• nat(X) 44> X = zero V (X = s(N) A nat(N)) 

• list(X) ^ (X = empty list) V (X = consJist(H,T) A list(T)) 
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• natJist(X) 43- (X = empty list) V (X = consJist(H,T) A nat(H) A natJist(T)) 

• natset(X) 4$ natJist(X) 

In the following, we will call Type the set of all the names of types. 
1.2.2 Typed Logic Descriptions 

Typed logic descriptions use a typed first order logic, where the only difference with classic 
first order logic is the addition of type information in quantifiers. For instance, instead of 
writing MX • p(X) we write VX £ T • p(X), where T 6 Type 

Definition 2. A Typed Logic Description is a closed typed first order logic formula of the 
form 

VXi € type\...MX n G type n »p(Xi, X n ) <^> TypedDef 

Where typei, ...,type n and the type names in all the quantifiers found in TypedDef belongs 
to Type. TypedDef, the definition part of the logic description, is a closed typed first order 
logic formula. Typed logic descriptions are denoted as TLD(p/n). 

Once again, we can make somme abbreviations. We omit the universal quantifiers to annotate 
the parameters with their types. Free variables in TypedDef are assumed to be existentially 
quantified and belonging to the type Term. The general form of a typed logic description is 
then written as: 

p{Xi : typei, ...,X n : type n ) <=> TypedDef 

Typed logic descriptions are close to declarative descriptions without functions and higher 
order defined in Ufl, which are the base to adapt the Deville methodology to the development 
of programs in Mercury^. 

In our variant of the methodology, firstly we construct a typed logic description. We can use 
the same technique of structural induction for non typed logic descriptions. The advantages 
of using typed logic descriptions instead of non typed are these: 

• Programmer must find a well founded relation over type\ x ... x type p , rather than finding 
it over TermP. 

• Structural forms are suggested by type definitions. 

• Programmer does not have to add manually type-checking literals. 



The typed logic description constructed with this technique can be directly translated to 
typed languages like Mercury and Godel. See the section 1.4. 

Type definitions can be also seen as skeletons on which can be applied techniques in order 
to derive a logic program. 

2 Some of the main features of Mercury are strong types, facilities for higher order programming and func- 
tional notation [Hi. 
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Figure 3: Transformation of a typed formula T into a non typed formula F n * 

1.3 Conversion from a Typed Logic Description into a Non Typed Logic 
Description 

We are interested in the development of Prolog programs, which are not typed. In order to 
obtain this, the typed logic description constructed needs to be expressed in classical first 
order logic. This is made by converting the typed logic description into a non typed logic 
description. 

It is required that the transformation preserves the declarative semantics of first order logic. 
We must define a notion of equivalence between a typed logic formula and a non typed logic 
formula. 

Definition 3. A typed logic formula Tp with free variables Xi, ...,X n belonging to types 
T\, T n is equivalent to a non typed logic formula F with the same free variables X±, ...,X n 
if and only if: 

• If there is an instance x±, x n of variables Xi, X n such that for some i, (1 < i < n), 
Xi is a term not belonging to the corresponding type Tj, then F is false. 

• For all the instances x\, ...,x n of variables X±, ...,X n such that X{ is a term belonging 
to the type T, F = Tp. 

Definition 4. (Transformation of a typed logic formula into a non typed logic formula). Let 
F be a typed logic formula, with free variables X±, ...,X n of types Ti, ...,T n . Let checkp be 
the non typed formula T\{X\) A ... A T n (X n ). 

F nt is the non typed logic formula resulting of the transformation showed in Fig. 3. 

Definition 5. (Transformation of a typed logic description to a non typed logic description) 
Let TLD(p/n) be the typed logic description 



p(X 1 :T 1 ,...,X n :T n )^Def 
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The resulting non typed logic description LD(p/n) is 

p{X u ...,X n ) e> T X {X{) 
A ... 

A T n {X n ) 
A Def nt 

Where Def nt is obtained by transforming the typed logic formula Def. 

Type-checking literals are introduced in the transformation. Much of these literals are redun- 
dant and can be eliminated. This is obtained by analysing types and modes in the generated 
logic program. 

1.4 Derivation of a logic program 

A first version of a procedure in the implementation logic language is derived from the non 
typed logic description^], following the syntactical transformation rules described in Qj. These 
rules are based in Clark completion. 

The final version of the procedure is obtained after these steps: 

• Eliminating redundant type-checking literals 

• Finding of a permutation of literals in the clauses that satisfy the specified directional- 
ities 

• Making language-dependent optimizations 

The first two steps are carried out by a combined static analysis of types and directionalities in 
the program. It is possible that no permutation satisfying the directionalities can be found. In 
such case, there are two alternatives: change the specification of directionalities in a way that 
a permutation can be found, or "split" the procedure to handle each directionality separately. 

Language-dependent optimizations for Prolog include cut introduction and forward and back- 
ward variable substitutions. 



1.5 Example 

We specify the procedure max-prefix/2, which find the maximum of the sums of all the prefixes 
of an integer list. 

3 when the target logic language is strongly typed, this derivation can be made directly from the typed logic 
description. 
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procedure max_prefix(L, M) 

Types: 

L : integerJist 
M : integer 

Relation: 

M is the maximum of the sums of all the prefixes of L 
Directionalities: 

(ground, var ground) : < 1 — 1 > 
(ground, ground) : < — 1 > 



We will solve this problem using structural induction with introduction of accumulators, 
which is a particular case of computational generalization. A new generalized procedure 
maxjpreftx-gen/3 is specified. 



procedure max_prefix_gen(L, M, A) 

Types: 

L : integerJist 
M : integer 
A : integer 
Relation: 

M = M'+A, where M' is the maximum of the sums of all the prefixes of 
L 

Directionalities: 

(ground, var ^ ground, ground) : < 1 — 1 > 
(ground, ground, ground) : < — 1 > 



We will use the structural induction technique with the generalized procedure. 

• Induction parameter: L 

• Well founded relation: proper list suffix 

• Structural forms: L=[ \ and 3H G Integer, T <G List • L = [H\T] 

• Structural cases: 

- If L= [ ], trivially M = A. 

— If L = [H \T] , let M' the maximum of the sums of prefixes of T, having accumulated 
H + A. M is the maximum between H + A and M'. 
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max_pref ix_gen(L, M, A) :- 
L = [] , 
M = A, 
integer (M) . 

max_pref ix_gen(L, M, A) :- 
L = [H | T] , 
plus(H, A, Al) , 
max_pref ix_gen(T, Ml, Al) , 
max(Al, Ml, M) . 

% max_prefix as a particular case of max_pref ix_gen 
I 

max_pref ix(L, M) :- 

max_pref ix_gen(L, M, -infinite) . 

Figure 4: Prolog code for max-prefix-gen/3 and max-prefix/2 

The resulting typed logic description is 

maxjprefix-gen{L : Integer dist, M : Integer, A : Integer) o 

L = [ ] A M = A 
V 3M' € Integer • 
L = [H\T] ' 

A max_prefix-gen(T, M', H + A) 
A max(H + A, M', M) 

After eliminating redundant type-checking literals we obtained the pure Prolog procedures 
presented in Fig. 4. We also present a possible implementation in Mercury in Fig. 5, using 
the correspondances in Fig. 2 to get the declarations of the procedure. 

2 Elements for a computational tool 

Our design of a computational tool for supporting the methodology is inspired by the FOLON 
environment j5J and the prototype SPG [O ]. 

One of our goals is the availability of the tool to interact with existing programming envi- 
ronments and to facilitate its extension with other methods and techniques of logic program 
development. In order to obtain this, each step of methodology is supported by one or many 
software components. Fig. 6 shows the basic component architecture of the tool. 

Our tool will be implemented to have two modes of use. An interactive mode, in which an user 
interface guides the programmer in all the steps of the development process. The programmer 
introduces all the needed data through that interface and obtain the documented source code 
of the built logic procedure. By means of a non interactive mode, the programmer feeds the 
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- pred max_pref ix_gen(integer_list , integer, integer). 

- mode max_pref ix_gen(in, out, in) is det . 

- mode max_pref ix_gen(in, in, in) is semidet . 



max_pref ix_gen(L, M, A) :- 
( L = [] , 
M = A 

L = [H | T] , 

max_pref ix_gen(T, Ml, A + H) , 
max(A + H, Ml, M) 



% max_prefix is a particular case of max_pref ix_gen 
% 

:- pred max_pref ix(integer_list , integer). 
:- mode max_pref ix(in, out) is det. 
:- mode max_pref ix(in, in) is semidet. 

max_pref ix(L, M) :- 
min_int (X) , 

max_pref ix_gen(L, M, X) . 



Figure 5: Mercury code for max-preftx-gen/3 and max-preftx/2 




Figure 6: Component Architecture of the tool 
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tool with heuristic information stored in external files. The tool generates automatically the 
source code according to the heuristic information given by the user. 

Now we will see more details of the tool components. 

2.1 Knowledge Base 

The knowledge base is the main component for the two modes of use of the tool, since all the 
other components interacts with it. 

There exists two kinds of knowledge to be stored in the base. On one hand, a technical 
knowledge which includes construction heuristics for typed logic descriptions and static anal- 
ysis. On the other hand, an object knowledge which contains all the elements required for the 
development process: specifications, types and logic programs already built. 

When the programmer develops new logic procedures and types, some relevant information 
about their development are stored in the knowledge base. In the same way, the programmer 
can adapt the techniques for constructing typed logic descriptions and add new techniques. 

2.2 Specification Editor 

The tool must be able to manipulate the specifications of logic procedures already developed. 
This is made by the specification editor component. 

Our specification format is naturally informal. It reduces the capabilities for automating the 
program verification, but it is more expressive. An informal specification does not exclude the 
use of formal notations or methods. This is why we believe that different tools of (semi)formal 
specifications could interact with this component. 

The specification editor will handle all the information about the specifications of logic proce- 
dures already developed. The programmer can develop a procedure from the scratch starting 
with a new specification or he can modify an existing specification to develop a new version 
of the procedure. 

The only automated task is the verification of consistency of the directionalities. If the 
verification is successful the tool will add the specification to its knowledge base. 

2.3 Type System 

The FOLON environment did not have a type system. It allowed the definition of a type as 
any arbitrary set of ground terms. One of the novelties of our tool is a separated component 
for the type system described in a previous section. 

The knowledge base will include some built-in types . The programmer will be able to add 
new types to the knowledge base. 

The programmer could manage several implementations of a type, this means, having differ- 
ents logic descriptions of type-checking for the same data structure. As an example we show 
two possible implementations of the stack data type. 
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stack _impll(X) o list(X) 

stack _impl2{X) 4$ X = empty_stack 

V X = push(E, S) A stackJmpl2(S) 

However, the programmer must be restricted to use only one implementation of a particular 
type, when he is developing a procedure that uses a type with many implementations. 

2.4 Logic Description Builder 

In the interactive mode, the programmer is guided by means of suggestion mechanisms on the 
knowledge base, which represent techniques for constructing typed logic descriptions. The 
knowledge base could be fed with new techniques. 

The techniques that will be available for constructing typed logic descriptions are: 

• Structural Induction 

• Tupling Generalization 

• Generalization by Acummulator Introduction 

The programmer will also be able to write directly the typed logic description in a file. The 
tool will parse it and will translate it automatically in a non typed logic description. 

2.5 Code Generators 

One of our goals is to be able to extend the tool with different code generators, one for 
each possible implementation language. At this moment we are just implementing the code 
generator for Prolog. 

The first subcomponent of a Prolog code generator is a derivator which receive the non typed 
logic description and transforms it to a first version of the logic procedure. 

This first version is processed by a type-mode analyzer, which will elminate redundant type- 
checking literals and will find a permutation of literals in the clauses that satisfies the specified 
directionalities. The analyzer will use abstract interpretation techniques and will take as 
starting point the results of the FOLON project about static analysis of types @ and program 
verification ||. 

If there is no permutation satisfying the directionalities, the tool will suggest two alternatives: 
either to generate separate versions of the procedure for each directionality, or to change the 
specification adapting the directionalities. 

The programmer will be able to modify manually the order of literals in the clauses or delete 
type-checking literals. After the analysis, the programmer will receive the source code with 
some messages about warnings on possible inconsistencies. 
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The Prolog code generator is enriched with language-dependent optimizers, based on program 
transformation techniques. Some optimizations like cut introductions can be made according 
to the specification of directionalities. 

For Mercury, the code generator is simpler. The declarations of types and modes are derived 
from the declaration of types and directionalities in the specification, following a correspon- 
dance like the one described in Fig. 2. The generation of code is made directly from the 
typed logic description, since the Mercury compiler makes itself the analysis of types and 
modes. Some mechanismes of source-to-source transformation for could be added to get a 
more optimal code. 

3 Conclusions 

Programming environments have two basic utilities: to facilitate the learning of a program- 
ming language and its computation model, and to help programmers to build correct pro- 
gramms in an efficient way. 

We have presented a variant of a general methodology for developing logic programs. This 
variant adds a simple type system and the notion of typed logic description, which give 
facilities for the development of programs in typed logic languages. 

We also present the design of a computational tool that supports our variant of the methodol- 
ogy. The tool is directed to two different publics. In one hand, students and novice program- 
mers who wants to learn the logic programming paradigm with small programs. In the other 
hand, more experienced programmers who looks for a semiautomatic support on development 
of middle-scale software systems. 

We believe that other techniques of logic program development can be adapted to the method- 
ology. Stepwise enhancement Q and synthesis from schemas ||] could be used at the step of 
the construction of the typed logic description. 

At this moment, we are working on the implementation of a prototype of the tool using the 
Mercury logic programming language. With the use of Mercury as implementation language 
we intend to show that logic programming is a good alternative to build CASE tools. 

Further work will study the adaptability of different techniques for logic program development 
in the tool, as well as the development of code generators for Mercury and other declarative 
languages. 

Acknowledgements. The first author thanks to Vladimir Tamara and Luis Quesada, as 
well as the anonymous reviewers, for their remarks and comments on first drafts of this paper. 
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